This present invention relates to ATA (Advanced Technology Attachment) device control, and more particularly to systems and methods for interfacing a host with an ATA device using an intervening packet data channel.
An xe2x80x9cATAxe2x80x9d device is a data device that complies with an ANSI (American National Standards Institute) ATA standard, for instance the standard xe2x80x9cAT Attachment with Packet Interface Extensionxe2x80x94(ATA/ATAPI-4)xe2x80x9d or one of its predecessors. Future ATA standards are also currently contemplated; devices compliant with these standards will also be xe2x80x9cATA devicesxe2x80x9d. Most personal computers have built-in ATA device support, and most of these come equipped with ATA internal hard drives.
The ATA standards define the physical, electrical, transport, and command protocols for the internal attachment of devices to computers via an ATA bus. Referring to FIG. 1, a typical configuration for a computer 20 capable of using one or more ATA data devices is shown. A host processor 22 communicates with main memory 24 (e.g., a memory controller attached to one or more memory modules via a memory bus) over a frontside bus 28. Host processor 22 (and main memory 24) can also communicate with a variety of other system peripherals through PCI (Peripheral Component Interconnect) bridge 26 and PCI local bus 30.
The bandwidth on PCI local bus 30 can be shared by a variety of computer components, some of which are depicted in FIG. 1. For instance, internal PCI-compliant devices such as modems, sound cards, video cards, etc. can be attached to computer 20 via PCI card slots 32 and 34 (the number of available slots varies from computer model to computer model) on the computer motherboard. In addition, USB (Universal Serial Bus) interface 36 provides a number of USB ports 38 for the attachment of a wide variety of external devices, such as a mouse, a keyboard, a digital camera, audio devices, printers, etc. And ATA host adapter 40 performs signal conversion between PCI local bus 30 and yet another bus, ATA bus 42.
ATA bus 42 is typically implemented as a multi-drop bus using a flexible 40-conductor cable having three 40-pin connectors, each of which can mate to a corresponding socket on the computer""s motherboard or on an ATA device (the ATA devices themselves mount within the computer case). Up to two ATA devices (e.g., devices 44 and 46 on FIG. 1) can share ATA bus 42. The primary device is known as device 0, or the xe2x80x9cmasterxe2x80x9d when two devices are present. The secondary device is known as device 1, or the xe2x80x9cslavexe2x80x9d. For most ATA operations, only one of devices 44 and 46 will respond to the host""s commands, that device being the one corresponding to the state of the xe2x80x9cDEVxe2x80x9d bit in the Device/Head Register (to be discussed shortly).
FIG. 2 illustrates several concepts related to ATA communication between an ATA host and an ATA device. ATA bus 42 uses an asynchronous interface protocol. Bus 42 comprises a 16-bit data bus 52, used to transfer storage data and register values to and from ATA device 44. Five-bit register addressing bus 54 is used by the host to tell device 44 which register""s contents are to be accessed. Device signals 56 and host signals 58 are used to indicate when bus contents are valid, to indicate whether a register access is a read or a write, to synchronize transfers, and to perform device resets.
All communications with a traditional ATA device 44 take place via register-delivered commands. Within device 44, a device controller 50 maintains a set of registers. In FIG. 2, this set of registers has been arranged in three groups: write-only registers 60 (registers that can only be written by the host); read-only registers 62 (registers that can only be written by the device); and read/write registers 64. A register-delivered command is executed whenever the host writes to the Command register. For instance, the READ MULTIPLE command causes multiple sectors to be read from the device in PIO data-in mode (Programmed Input/Output mode data transfers are performed by the host processor utilizing programmed register accesses to the Data register). To perform a READ MULTIPLE command, the host places the number of data sectors to be transferred in the Sector Count register, the starting sector number in the Sector Number register, the starting cylinder number in the Cylinder High/Cylinder Low registers, and the device number and starting head number in the Device/Head register. The READ MULTIPLE command code (C4h) is then written to the Command register, causing ATA device 44 to evaluate the other register""s contents and perform the requested read.
Device 44 indicates the status of the command using the bit fields of the Status register. If an error occurs, device 44 will report on the error using the Error register and several other registers. Note that it is the host""s job to read the registers and ascertain the status of the device.
The ATA standard includes an alternative to register-delivered commands that is better suited to devices such as CD-ROM and tape devices. The ATAPI (ATA Packet Interface) specifies a method for controlling a storage device over an ATA bus using packet-delivered commands. Although an ATAPI device and an ATA device can share an ATA bus, a single device cannot identify itself simultaneously as both an ATA device and as an ATAPI device. An ATAPI device supports a very small subset of the traditional ATA command setxe2x80x94for most of its functions, an ATAPI device receives ATAPI packet-delivered transport protocol commands. An ATAPI packet is received by the device as data upon receipt by the device of the ATA ATAPI-specific PACKET command in the Command register.
The ATAPI transport protocol, like traditional ATA, was designed for use with internally-mounted drives and with a host that places ATAPI packets directly on the ATA bus. But because most functions of an ATAPI device can be exercised using ATAPI packets, methods have now been devised to use an intermediate transport protocol and a different physical transport mediaxe2x80x94those provided by USBxe2x80x94to allow external connection of an ATAPI device to a host computer. This method relies only on the packet-delivered commands of ATAPI to communicate with an ATAPI device. FIG. 3 illustrates a communication stack 70 that operates according to such a method.
In FIG. 3, a physical device 90, which includes an ATAPI device 100, physically connects to a host 80 via a USB PHY connection 99, e.g., a USB cable or an intervening USB hub. When host 80 desires to execute an ATAPI function on ATAPI device 100, host 80 calls ATAPI driver 82. ATAPI driver 82 sends an appropriate ATAPI transport protocol command, along with an indication as to the amount of data (if any) that is expected to be transferred and an indication of the xe2x80x9cLogical Unitxe2x80x9d that is to be addressed, to MSC (Mass Storage Class) driver 84.
Logically, MSC driver 84 communicates with MSC logical device 96 on physical device 90 to transport the ATAPI command packet and data between host 80 and physical device 90. Together, driver 84 and logical device 96 operate according to the specification xe2x80x9cUniversal Serial Bus Mass Storage Classxe2x80x94Bulk-Only Transportxe2x80x9d, Rev. 1.0, USB Implementers Forum, Sep. 31, 1999. According to this specification, two USB logical pipes (Bulk-In Pipe 110 and Bulk-Out Pipe 112) are established between the two USB endpoints (in addition to the Default Pipe 114 that exists between USB driver 86 and USB logical device 94). The two devices pass MSC-formatted command and data packets over these two logical pipes. Physically, driver 84 and logical device 96 communicate via the USB PHY 99 that is established between USB host controller 88 (on host 80) and USB bus interface 92 (on device 90).
ATAPI command execution proceeds in three MSC steps, as shown in flowchart 120 of FIG. 4. The ATAPI transport protocol packet is encapsulated in an MSC-valid and-meaningful command block wrapper (CBW) at command transport step 122. Using bulk-out pipe 112, the CBW is communicated to MSC logical device 96. Then, if the host is writing data to the storage device, data-out block 124 transfers the data to MSC logical device 96 over bulk-out pipe 112. Or, if the host is reading data from the storage device, data-in block 126 transfers the data to MSC driver 84 over bulk-in pipe 110. Finally, in status transport step 128, MSC logical device 96 transfers a command status wrapper (CSW) back o MSC driver 84, indicating that the command has completed.
Returning to FIG. 3, two additional blocks, ATA host 97 and ATA interface 98, complete the communication path to ATAPI device 100. ATA host 97 issues ATA PACKET commands to ATAPI device 100, and then controls transfer of ATAPI command packets and data between ATAPI logical host 96 and ATAPI device 100. ATA interface 98 provides the low-level timing, handshaking, and signal-driving necessary to communicate with ATAPI device 100 over ATA PHY 101.
Although the ATAPI-over-USB functionality provided by a configuration such as that shown in FIG. 3 is certainly useful, it is recognized herein that it also possesses a number of inherent limitations. For instance, there is no mechanism to allow full visibility by ATAPI driver into the registers of ATAPI device 100xe2x80x94when ATAPI driver 82 issues an ATAPI command, it receives back only a status indication as to whether the command passed, failed, or caused a phase error. Perhaps even more important, the configuration in FIG. 3 only allows the host to issue ATAPI packet-delivered commands to ATAPI devices.
The disclosed embodiments contemplate a packet-based method and apparatus for executing register-delivered ATA commands. These embodiments provide many benefits. First, a host can use, e.g., a USB plug-and-play connection to access an external ATA hard drive or other non-ATAPI ATA device. This allows the main benefits of an ATA hard drive (large storage size at low cost) to be offered in a portable or add-on configuration. Second, these embodiments can allow a host to have full flexible access to an ATAPI device""s ATA registers and to execute up to the full set of ATA commands that the ATAPI device can recognize. Also, a host without an ATA hardware bus, a full ATA bus, or one where it is desired to operate without the difficulties of asynchronous communication with an ATA device, can attach itself to an ATA device via a packet port. And finally, some of the disclosed embodiments can operate within the design parameters of the USB MSC protocol, making the command transport implementation straightforward. In a particularly preferred implementation, a complete ATA register-delivered command sequence can be performed using a single CBW/Data/CSW MSC transaction-this not only makes the implementation efficient, but solves many timing issues that could occur were each register operation placed in a separate packet.
In one aspect of the invention, a method is disclosed for controlling an ATA device using packet-based communication between a host and a packet-to-ATA bridge. The host formats the ATA register accesses necessary to execute a given ATA register-delivered transaction into a command block. The host transmits the command block to the packet-to-ATA bridge in a packet format. The bridge parses the command block into a sequence of ATA operations necessary to execute the given ATA register-delivered transaction. The bridge then communicates with an ATA device attached to the bridge via an ATA interface to execute the sequence of ATA operations on the ATA device. When the given ATA register-delivered transaction requests the values for one or more registers on the ATA device, the bridge returns the register values to the host in packet format.
The portions of the method above that are performed by the bridge form another aspect of the invention. The methods can be performed by hardware, software, or a combination of the two.
In yet another aspect of the invention, an apparatus comprising a packet-to-ATA bridge is disclosed. The bridge comprises a packet data interface to receive ATA register-delivered-command packets and data packets from a remote host, and to transmit data and status packets to the remote host. The bridge also comprises an ATA interface to transmit ATA bus host signals to an ATA device and receive ATA device signals from the device. Buffer memory is included to buffer data between the packet data interface and the ATA interface. An ATA register protocol adapter connects to the ATA interfacexe2x80x94this adapter is capable of performing ATA register operations with an ATA device attached to the ATA signal interface. And an ATA command protocol adapter is included to parse a command packet into a sequence of ATA register operations and cause that sequence of operations to be performed by the ATA register protocol adapter.
The apparatus can be the bridge alone, e.g., implemented on an integrated circuit. The apparatus can also be a xe2x80x9csmartxe2x80x9d cable that includes the bridge. Or, the apparatus can comprises both the bridge and the ATA device in a single package.